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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
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Abstract 


This document clarifies the procedures for the control of the label 
used on an output/downstream interface of the egress node of a Label 
Switched Path (LSP). This control is also known as "Egress Control". 
Support for Egress Control is implicit in Generalized Multi-Protocol 
Label Switching (GMPLS) Signaling. This document clarifies the 
specification of GMPLS Signaling and does not modify GMPLS signaling 
mechanisms and procedures. 


1. Background 


The ability to control the label used on the output/downstream 
interface of an egress node was one of the early requirements for 
GMPLS. In the initial GMPLS documents, this was called "Egress 
Control". As the GMPLS documents progressed, the ability to control 
a label on an egress interface was generalized to support control of 
a label on any interface. This generalization is seen in Section 6 
of [RFC3471] and Section 5.1 of [RFC3473]. When this functionality 
was generalized, the procedures to support control of a label at the 
egress were also generalized. Although the result was intended to 
cover egress control, this intention is not clear to all. This note 
reiterates the procedures to cover control of a label used on an 
egress output/downstream interface. 
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For context, the following is the text from the GMPLS signalling 
document dated June 2000 about how ERO (Explicit Route Object) for 
egress control: 


6. Egress Control 


The LSR at the head-end of an LSP can control the termination of 
the LSP by using the ERO. To terminate an LSP on a particular 
outgoing interface of the egress LSR, the head-end may specify the 
IP address of that interface as the last element in the ERO, 
provided that interface has an associated IP address. 


There are cases where the use of IP address doesn’t provide enough 
information to uniquely identify the egress termination. One case 
is when the outgoing interface on the egress LSR is a component 
link of a link bundle. Another case is when it is desirable to 
"splice" two LSPs together, i.e., where the tail of the first LSP 
would be "spliced" into the head of the second LSP. This last 
case is more likely to be used in the non-PSC classes of links. 


6.2. Procedures 


The Egress Label subobject may appear only as the last subobject 
in the ERO/ER. Appearance of this subobject anywhere else in the 
ERO/ER is treated as a "Bad strict node" error. 


During an LSP setup, when a node processing the ERO/RR performs 
Next Hop selection finds that the second subobject is an Egress 
Label Subobject, the node uses the information carried in this 
subobject to determine the handling of the data received over that 
LSP. Specifically, if the Link ID field of the subobject is non 
zero, then this field identifies a specific (outgoing) link of the 
node that should be used for sending all the data received over 
the LSP. If the Label field of the subobject is not Implicit NULL 
label, this field specifies the label that should be used as an 
outgoing label on the data received over the LSP. 


Procedures by which an LSR at the head-end of an LSP obtains the 
information needed to construct the Egress Label subobject are 
outside the scope of this document. 


2. Egress Control Procedures 
This section is intended to complement Sections 5.1.1 and 5.2.1 of 
[RFC3473]. The procedures described in those sections are not 


modified. This section clarifies procedures related to the label 
used on an egress output/downstream interface. 
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The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2.1. ERO Procedures 


Egress Control occurs when the node processing an ERO is the egress 
and the ERO contains one or more subobjects related to the 
output/downstream interface. In this case, the outgoing/downstream 
interface is indicated in the ERO as the last listed local interface. 
Note that an interface may be numbered or unnumbered. 


To support Egress Control, an egress checks to see whether the 
received ERO contains an outgoing/downstream interface. If it does, 
the type of the subobject or subobjects following the interface is 
examined. If the associated LSP is unidirectional, one subobject is 
examined. Two subobjects are examined for bidirectional LSPs. If 
the U-bit of the subobject being examined is clear (0), then the 
value of the label MUST be used for transmitting traffic associated 
with the LSP on the indicated outgoing/downstream interface. 


If the U-bit of the subobject being examined is set (1), then the 
value of the label is used for upstream traffic associated with the 
bidirectional LSP. Specifically, the label value will be used for 
the traffic associated with the LSP that will be received on the 
indicated outgoing/downstream interface. 


Per [RFC3473], any errors encountered while processing the ERO, 
including if the listed label(s) are not acceptable or cannot be 
supported in forwarding, SHOULD result in the generation of a PathErr 
message with the error code "Routing Error" and error value of "Bad 
Explicit Route Object". 


2.2. RRO Procedures 


If an ERO is used to specify outgoing interface information at the 
egress and label recording is indicated for the LSP, the egress 
should include the specified interface information and the specified 
label or labels in the corresponding RRO (Route Record Object). 


3. Security Considerations 
This document clarifies procedures defined in [RFC3473] but does not 


define any new procedures. As such, no new security considerations 
are introduced. 
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This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
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